Over time, the design of microprocessors, and the software executed by them, has grown in complexity. As a result, there is an increasing need to “debug” the design of microprocessors. Debugging, in this context, is the process of identifying why a particular instruction, executed by a microprocessor, led to an unintended result. Thus, the root cause of the unintended result (i.e., a problem or a “bug”) may include the design of the microprocessor or the design of the software executed by the microprocessor.
Microprocessors execute instructions using an internal clock signal. A component of the microprocessor, referred to as a clock generation component, may receive a clock signal from a source external to the microprocessor. The clock generation component may thereafter generate the internal clock signal for use by components of the microprocessor. The components of the microprocessor perform functions using the internal clock signal generated by the clock generation component.
To illustrate, a microprocessor may execute two or more instructions, in a sequence of instructions, in a pipeline fashion by processing instructions in several stages. At a rising edge of an internal clock signal, components of the microprocessor may perform a first stage operation on instruction A. At the next rising edge of the internal clock signal, the components of the microprocessor may perform a second stage operation on instruction A, and a first stage operation on instruction B, and so on. Thus, in this example, at each rising edge of the internal clock signal, the execution of an instruction may be initiated, and therefore, the value maintained by storage elements (such as flip-flops and latches) of the microprocessor may change.
One approach for debugging the design of a microprocessor involves a user causing a microprocessor to execute the sequence of instructions, and if a problem is detected (for example, the microprocessor appears to be hanging), the user transmits a signal (a “stop signal”) using a clock stop mechanism, to the microprocessor, to stop the generation of the internal clock signal. Components of the microprocessor cease to receive the internal clock signal once the internal clock signal is no longer generated. Since the internal clock signal drives the performance of the components of the microprocessor, when the components of the microprocessor no longer receive the internal clock signal, the components of the microprocessor cease performing their functions. In this way, once the components of the microprocessor no longer receive the internal clock signal, no further instructions are executed and the state of the microprocessor is maintained. The state of the microprocessor may be subsequently retrieved for use in debugging the design of the microprocessor.
The clock stop mechanism may be implemented using the JTAG (Joint Test Access Group) protocol, which is a commonly used name for referring to the IEEE standard 1149.1. The JTAG protocol specifies how to control and monitor the pins of compliant devices, and may be used to (a) stop the generation of an internal clock signal received by components of the microprocessor and (b) retrieve the contents of flip-flops and registers of the microprocessor.
While this approach allows the state of the microprocessor to be preserved contemporaneously with the receipt, by the microprocessor, of the stop signal, this preserved state may be long after the execution of the instruction that caused the problem. Thus, a user is required to make educated guesses as to the reason(s) the problem was encountered based on the preserved state of the microprocessor.
Another approach for debugging a sequence of instructions executed by a microprocessor involves designing, in the microprocessor, event logic that detects the occurrence of a particular event, such as an undesirable state of the microprocessor. Whenever that event is detected by the event logic, the event logic may generate a stop signal to cease the generation of clock signals received by components of the microprocessor, thereby preserving the state of the microprocessor contemporaneous with the occurrence of the event. This approach has limited value for debugging the design of the microprocessor because, if the microprocessor is configured to include event logic that is designed to detect a particular event, then typically the particular event is not indicative of the problem that is causing the bug in the execution of instructions by the microprocessor since the designer of the microprocessor is likely aware that such a problem may occur. In other words, unknown problems typically cause more bugs than known problems.
Consequently, what is needed in the art is an approach for debugging the design of a microprocessor, which does not incur the disadvantages associated with the prior approaches. The approaches described in this section are approaches that could have been pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.